![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Wireless Networking Handbook
Documenting RequirementsTo adequately support the remaining phases of the project, be sure to clearly document the requirements. Without good documentation, requirements can become unclear as time passes and memories lapse. The handover of project information from person to person can also dilute original intentions. To make matters worse, the analysts responsible for defining the requirements could leave and be unavailable during the design phase. Undocumented requirements also make it too easy for changes to occur in an uncoordinated fashion during later stages of the project, making it difficult to find the correct solution. Therefore, the team should develop a requirements document containing, as a minimum, an illustration of the organizations high-level business processes (in other words, how the company or applicable organization(s) operates) and definition of each requirement type. The following list shows the major elements of a requirements document:
To produce this document, the team should refer to all information gathered, such as interview and JAD meeting notes, regulations, facility evaluations, and prototypes. Verifying and Validating RequirementsThe importance of requirements cant be overstatedinaccurate requirements lead to solutions that dont adequately support the needs of the users. Thus, the project team should verify and validate the requirements. Verification checks if the requirements are accurate based on those needs. Validation proves whether the requirements fully represent the needs of the users and conform to the companys business processes. Therefore, these two quality control tests answer these questions: Verification: Are we building the product right? Validation: Are we building the right product? Verifying RequirementsIts best to verify requirements first, and then validate them. You want to be sure the requirements are okay before testing whether they meet user needs. The most important verification point is to be sure the requirements are complete and unambiguous. Complete requirements describe all aspects of the needs of the users and organization. For example, incomplete requirements might state needs for users and existing systems, but not identify anything about the environment, such as the presence of potential electromagnetic interference. For wireline systems, this might not be critical, but it could have serious impact on the operation of radio-based products. Requirements should be unambiguous to avoid needing clarification later. Ambiguous requirements force the designer to seek the finer details. To save time, most designers will guess the values of the remaining details, causing the designer to choose inappropriate characteristics. For most projects, you can verify the requirements by referring to the requirements document and answering these questions:
Validating RequirementsThe best method to validate requirements is to build a prototype as a model that represents the requirements. For application development, you can build a software prototype using a fourth-generation language, such as Powersofts Powerbuilder, that contains the screens and some functionality to implement the requirements. For off-the-shelf applications and hardware, of course, vendors normally allow enough evaluation timeone or two monthsto test the application. For either case, you can have the users exercise the prototype and observe whether their needs will be met. Baselining RequirementsThe baselining, or standardizing, of requirements involves final documenting and approval of the requirements. This process makes the requirements official, and you should only change them by following an agreed-upon process. Who approves the requirements? Ultimately, the customer representative should give the final sign-off; however, an analyst should endorse the requirements in terms of their accuracy and efficacy. If youre deploying the system under a contract, other people, such as the project manager and contract official, may also need to offer approvals. Be certain to indicate that both the organization and modification team consider the set of requirements as a firm baseline from which to design the network. Updating the Project PlanAfter defining the requirements, its time to revisit the planning elements you prepared earlier in the project. At first, you probably based the project WBS, schedule, and budget on incomplete and assumed requirements. The actual requirements, though, might cast the project in a different light. For example, maybe you found during the user interviews that information security was more important than you had expected. This might create a need to modify the WBSand possibly the schedule and budgetto research security technologies and products. Or you might have planned to spend three weeks during installation setting up 150 computers, but during the interviews, you found there will only be 75. This information could enable you to cut back the schedule, or reallocate the time to a task that might take longer than expected. With an updated project plan and final requirements, the project team is ready to move into the design phase of the project.
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement. |